home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-tuba-clnp-02.txt < prev    next >
Text File  |  1993-03-03  |  45KB  |  1,368 lines
  1.  
  2.  
  3. IETF                            Page 1
  4. January 6, 1993          CLNP for TUBA             Internet Draft
  5.  
  6.  
  7.               Use of ISO CLNP in TUBA Environments
  8.  
  9.  
  10.               David M. Piscitello
  11.                     Bellcore
  12.                   dave@sabre.bellcore.com
  13.  
  14.  
  15.                        Status of this Memo
  16.  
  17. This document is an Internet Draft.  Internet Drafts are working
  18. documents of the Internet Engineering Task Force (IETF), its
  19. Areas, and its Working Groups. Note that other groups may also
  20. distribute working documents as Internet Drafts.
  21.  
  22. Internet Drafts are draft documents valid for a maximum of six
  23. months. Internet Drafts may be updated, replaced, or obsoleted by
  24. other documents at any time.  It is not appropriate to use
  25. Internet Drafts as reference material or to cite them other than
  26. as a "working draft" or "work in progress."
  27.  
  28. Please check the Internet Draft abstract listing contained in the
  29. IETF Shadow Directories (cd internet-drafts) to learn the current
  30. status of this or any other Internet Draft.
  31.  
  32. This Internet-Draft specifies a profile of the ISO 8473
  33. Connectionless-mode Network Layer Protocol (CLNP, [1]) for use in
  34. conjunction with RFC 1347, TCP/UDP over Bigger Addresses (TUBA,
  35. [2]).  This draft document will be submitted to the RFC editor as
  36. a protocol specification. Distribution of this memo is unlimited.
  37. Please send comments to dave@eve.bellcore.com.
  38.  
  39.  
  40.                             Abstract
  41.  
  42. This document describes the use of CLNP to provide the lower-
  43. level service expected by Transmission Control Protocol (TCP,
  44. [3]) and User Datagram Protocol (UDP, [4]). CLNP provides
  45. essentially the same datagram service as Internet Protocol (IP,
  46. [5]), but offers a means of conveying bigger network addresses
  47. (with additional structure, to aid routing).
  48.  
  49. While the protocols offer nearly the same services, IP and CLNP
  50. are not identical. This document describes a means of preserving
  51. the semantics of IP information that is absent from CLNP while
  52. preserving consistency between the use of CLNP in Internet and
  53. OSI environments. This maximizes the use of already-deployed CLNP
  54. implementations.
  55.  
  56.  
  57.                          Acknowledgments
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69. IETF                            Page 2
  70. Internet Draft            CLNP for TUBA           January 6, 1993
  71.  
  72.  
  73. Many thanks to Ross Callon of Digital Equipment, Brian Carpenter
  74. of CERN, and Dave Katz of Cisco Systems for their assistance in
  75. composing this text.
  76.  
  77.  
  78.                            Conventions
  79.  
  80. The following language conventions are used in the items of
  81. specification in this document:
  82.  
  83.    o+ Must, Shall, or Mandatory -- the item is an absolute
  84.      requirement of the specification.
  85.  
  86.    o+ Should or Recommended -- the item should generally be
  87.      followed for all but exceptional circumstances.
  88.  
  89.    o+ May or Optional -- the item is truly optional and may be
  90.      followed or ignored according to the needs of the
  91.      implementor.
  92.  
  93.  
  94. 1.  Terminology
  95.  
  96. To the extent possible, this document is written in the language
  97. of the Internet. For example, packet is used rather than
  98. "protocol data unit", and "fragment" is used rather than
  99. "segment".  There are some terms that carry over from OSI; these
  100. are, for the most part, used so that cross-reference between this
  101. document and RFC994 or ISO 8473 is not entirely painful.  OSI
  102. acronyms are for the most part avoided.
  103.  
  104.  
  105. 2.  Introduction
  106.  
  107. The goal of this specification is to allow compatible and
  108. interoperable implementations to encapsulate TCP and UDP packets
  109. in CLNP data units. It is assumed that readers are familiar with
  110. RFC 791 and, to a lesser extent, RFC 994 and ISO 8473.  This
  111. document is compatible with (although more restrictive than) ISO
  112. 8473; specifically, the order, semantics, and processing of CLNP
  113. header fields is consistent between this and ISO 8473.  However,
  114. it is intended that this document be able to stand on its own
  115. without reference to ISO 8473, at least with respect to
  116. implementing CLNP to provide the lower-level service expected by
  117. TCP and UDP.
  118.  
  119. [Editor's Note: RFC 994 contains the Draft International Standard
  120. version of ISO CLNP [6], in ASCII text. This is not the final
  121. version of the ISO protocol specification; however, it should
  122. provide sufficient background for the purpose of understanding
  123. the relationship of CLNP to IP, and the means whereby IP
  124. information is to be encoded in CLNP header fields. Postscript
  125. versions of ISO CLNP and associated routing protocols are
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135. IETF                            Page 3
  136. January 6, 1993          CLNP for TUBA             Internet Draft
  137.  
  138.  
  139. available via anonymous FTP from merit.edu, and may be found in
  140. the directory /pub/iso.]
  141.  
  142.  
  143. 3.  Overview of CLNP
  144.  
  145. ISO CLNP is a datagram network protocol. It provides
  146. fundamentally the same underlying service to a transport layer as
  147. IP. CLNP provides essentially the same maximum datagram size, and
  148. for those circumstances where datagrams may need to traverse a
  149. network whose maximum packet size is smaller than the size of the
  150. datagram, CLNP provides mechanisms for fragmentation (data unit
  151. identification, fragment/total length and offset). Like IP, a
  152. checksum computed on the CLNP header provides a verification that
  153. the information used in processing the CLNP datagram has been
  154. transmitted correctly, and a lifetime control mechanism ("Time to
  155. Live") imposes a limit on the amount of time a datagram is
  156. allowed to remain in the internet system. As is the case in IP, a
  157. set of options provides control functions needed or useful in
  158. some situations but unnecessary for the most common
  159. communications.
  160.  
  161. Table 1 provides a high-level comparison of CLNP to IP:
  162.  
  163.  
  164.  
  165. Function                | ISO CLNP              | DOD IP
  166. ------------------------|-----------------------|-----------------------
  167. Version Identifier      | 1 octet               | 4 bits
  168. Header Length           | indicated in octets   | in 32-bit words
  169. Total Length            | 16 bits, in octets    | 16 bits, in octets
  170. Data Unit Identifier    | 16 bits               | 16 bits
  171. Flags                   | Fragmentation allowed,| Don't Fragment,
  172.                         | More Fragments        | More Fragments,
  173.                         | Suppress Error Reports| <not defined>
  174. Fragment offset         | 16 bits, in octets    | 13 bits, 8-octet units
  175. Lifetime (Time to live) | 500 msec units        | 1 sec units
  176. Higher Layer Protocol   | Selector in address   | PROTOcol (assigned #)
  177. Header Checksum         | 16-bit (Fletcher)     | 16-bit
  178. Addressing              | Variable length       | 32-bit fixed
  179. Options                 | Security              | Security
  180.                         | Priority              | Precedence bits in TOS
  181.                         | Complete Source Route | Strict Source Route
  182.                         | Quality of Service    | Type of Service
  183.                         | Partial Source Route  | Loose Source Route
  184.                         | Record Route          | Record Route
  185.                         | Padding               | Padding
  186.                         | <defined herein>      | Timestamp
  187.  
  188.  
  189.  
  190.                 Table 1. Comparison of IP to CLNP
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201. IETF                            Page 4
  202. Internet Draft            CLNP for TUBA           January 6, 1993
  203.  
  204.  
  205. Note that the encoding of options differs between the two
  206. protocols, as do the means of higher level protocol
  207. identification. Note also that CLNP and IP differ in the way
  208. header and fragment lengths are represented, and that the
  209. granularity of lifetime control (time-to-live) is finer in CLNP.
  210. Some of these differences are not considered "issues", as CLNP
  211. provides flexibility in the way that certain options may be
  212. specified and encoded (this will facilitate the use and encoding
  213. of certain IP options without change in syntax); others, e.g.,
  214. higher level protocol identification and timestamp, must be
  215. accommodated in a transparent manner in this profile for correct
  216. operation of TCP and UDP, and continued interoperability with OSI
  217. implementations. Section 4 describes how header fields of CLNP
  218. must be populated to satisfy the needs of TCP and UDP.
  219.  
  220. Errors detected during the processing of a CLNP datagram may be
  221. reported using CLNP Error Reports. Implementations of CLNP for
  222. TUBA environments must be capable of processing Error Reports
  223. (this is consistent with the 1992 version of the ISO 8473
  224. standard).  Control messages (e.g., echo request/reply and
  225. redirect) are similarly handled in CLNP, i.e., identified as
  226. separate network layer packet types.  The relationship between
  227. CLNP Error and Control messages and Internet Control Message
  228. Protocol (ICMP, [7]), and issues relating to the handling of
  229. these messages is described in Section 5.
  230.  
  231. The composition and processing of a TCP pseudo-header when CLNP
  232. is used to provide the lower-level service expected by TCP and
  233. UDP is described in Section 6.
  234.  
  235.  
  236.  
  237. 4.  Proposed Internet Header using CLNP
  238.  
  239. A summary of the contents of the CLNP header, as it is proposed
  240. for use in TUBA environments, is illustrated in Figure 4-1:
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267. IETF                            Page 5
  268. January 6, 1993          CLNP for TUBA             Internet Draft
  269.  
  270.  
  271.  
  272.     0                   1                   2                   3
  273.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  274.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  275.    |        ........Data Link Header........       | NLP ID        |
  276.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  277.    |Header Length  |     Version   | Lifetime (TTL)|Flags|  Type   |
  278.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  279.    |        Fragment Length        |           Checksum            |
  280.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  281.    | Dest Addr Len |               Destination Address...          |
  282.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  283.    |               ... Destination Address...                      |
  284.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  285.    |               ... Destination Address...                      |
  286.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  287.    |               ... Destination Address...                      |
  288.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  289.    |               ... Destination Address...                      |
  290.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  291.    | PROTO field   | Src  Addr Len |  Source  Address...           |
  292.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  293.    |               ... Source Address...                           |
  294.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  295.    |               ... Source Address...                           |
  296.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  297.    |               ... Source Address...                           |
  298.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  299.    |               ... Source Address...                           |
  300.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  301.    |       ... Source Address      |   Reserved    | Data Unit...  |
  302.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  303.    | ...Identifier |         Fragment Offset       |Total Length.. |
  304.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  305.    | ... of Packet |             Options...                        |
  306.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  307.    |                                                               |
  308.    :                                                               :
  309.    |                    Options  (see Table 1)                     |
  310.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  311.  
  312.           Note that each tick mark represents one bit position.
  313.  
  314.  
  315.  
  316.                         Figure 4-1. CLNP for TUBA
  317.  
  318. Note 1: For illustrative purposes, Figure 4-1 depicts Destination and
  319.         Source Addresses having a length of 19 octets, including the
  320.         PROTO/reserved field. In general, addresses can be variable
  321.         length, up to a maximu of 20 octets, including the
  322.         PROTO/reserved field.
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. IETF                            Page 6
  334. Internet Draft            CLNP for TUBA           January 6, 1993
  335.  
  336.  
  337. Note 2: Due to differences in link layer protocols, it is not possible
  338.         to ensure that the packet starts on an even alignment.  Note,
  339.         however, that many link level protocols over which CLNP is operated
  340.         happen to use a odd length link (e.g., 802.2). (As profiled in
  341.         Figure 4-1, the rest of the CLNP packet is even-aligned.)
  342.  
  343.  
  344. The encoding of CLNP fields for use in TUBA environments is as
  345. follows.
  346.  
  347. 4.1  Network Layer Protocol Identification (NLP ID)
  348.  
  349. This one-octet field identifies this as the ISO 8473 protocol; it
  350. must set to binary 1000 0001.
  351.  
  352. 4.2  Header Length Indication (Header Length)
  353.  
  354. Header Length is the length of the CLNP header in octets, and
  355. thus points to the beginning of the data. The value 255 is
  356. reserved. The header length is the same for all fragments of the
  357. same (original) CLNP packet.
  358.  
  359. [Note: General purpose CLNP implementations must be willing to
  360. accept addresses of variable length up to 20 octets. In
  361. particular, implementations that are expected to support both
  362. GOSIP and RFC 1237 [13] style addresses in addition to "TUBA"
  363. addresses [8].  must be capable of dealing with 20-octet
  364. addresses.]
  365.  
  366. 4.3  Version
  367.  
  368. This one-octet field identifies the version of the protocol; it
  369. must be set to a binary value 0000 0001.
  370.  
  371. 4.4  Lifetime (TTL)
  372.  
  373. Like the TTL field of IP, this field indicates the maximum time
  374. the datagram is allowed to remain in the internet system.  If
  375. this field contains the value zero, then the datagram must be
  376. destroyed.  This field is modified in internet header processing.
  377. The time is measured in units of 500 milliseconds, but since
  378. every module that processes a datagram must decrease the TTL by
  379. at least one even if it process the datagram in less than 500
  380. millisecond, the TTL must be thought of only as an upper bound on
  381. the time a datagram may exist.  The intention is to cause
  382. undeliverable datagrams to be discarded, and to bound the maximum
  383. CLNP datagram lifetime. [Like IP, the colloquial usage of TTL in
  384. CLNP is as a coarse hop-count.]
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399. IETF                            Page 7
  400. January 6, 1993          CLNP for TUBA             Internet Draft
  401.  
  402.  
  403. 4.5  Flags
  404.  
  405. Three flags are defined. These occupy bits 0, 1, and 2 of the
  406. Flags/Type octet:
  407.  
  408.           0   1   2
  409.         +---+---+---+
  410.         | F | M | E |
  411.         | P | F | R |
  412.         +---+---+---+
  413.  
  414. The Fragmentation Permitted (FP) flag, when set to a value of one
  415. (1), is semantically equivalent to the "may fragment" value of
  416. the Don't Fragment field of IP; similarly, when set to zero (0),
  417. the Fragmentation Permitted flag is semantically equivalent to
  418. the "Don't Fragment" value of the Don't Fragment Flag of IP.
  419.  
  420. [Editor's Note: If the Fragmentation Permitted field is set to
  421. the value O, then the Data Unit Identifier, Fragment Offset, and
  422. Total Length fields are not present. This denotes a single
  423. fragment datagram. In such datagrams, the Fragment Length field
  424. contains the total length of the datagram.]
  425.  
  426. The More Fragments flag of CLNP is semantically and syntactically
  427. the same as the More Fragments flag of IP; a value of one (1)
  428. indicates that more segments/fragments are forthcoming; a value
  429. of zero (0) indicates that the last octet of the original packet
  430. is present in this segment.
  431.  
  432. The Error Report (ER) flag is used to suppress the generation of
  433. an error message by a host/router that detects an error during
  434. the processing of a CLNP datagram; a value of one (1) indicates
  435. that the host that originated this datagram thinks error reports
  436. are useful, and would dearly love to receive one if a host/router
  437. finds it necessary to discard its datagram(s).
  438.  
  439. 4.6  Type field
  440.  
  441. The type field distinguishes data CLNP packets from Error Reports
  442. from Echo packets. The following values of the type field apply:
  443.  
  444.  
  445.   0   1   2   3   4   5   6   7
  446. +---+---+---+---+---+---+---+---+
  447. | flags     | 1 | 1 | 1 | 0 | 0 |  => Encoding of Type = data packet
  448. +---+---+---+---+---+---+---+---+
  449. | flags     | 0 | 0 | 0 | 0 | 1 |  => Encoding of Type = error report
  450. +---+---+---+---+---+---+---+---+
  451. | flags     | 1 | 1 | 1 | 1 | 0 |  => Encoding of Type = echo request
  452. +---+---+---+---+---+---+---+---+
  453. | flags     | 1 | 1 | 1 | 1 | 1 |  => Encoding of Type = echo reply
  454. +---+---+---+---+---+---+---+---+
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465. IETF                            Page 8
  466. Internet Draft            CLNP for TUBA           January 6, 1993
  467.  
  468.  
  469. Error Report packets are described in Section 5.
  470.  
  471. Echo and its use is described in RFC 1139 [14].
  472.  
  473. 4.7  Fragment Length
  474.  
  475. Like the Total Length of the IP header, the Fragment length field
  476. contains the length in octets of the fragment (i.e., this
  477. datagram) including both header and data. [Note: CLNP also has a
  478. Total Length field, that contains the length of the original
  479. datagram; i.e., the sum of the length of the CLNP header plus the
  480. length of the data submitted by the higher level protocol, e.g.,
  481. TCP or UDP).
  482.  
  483. 4.8  Checksum
  484.  
  485. A checksum is computed on the header only. It is verified at each
  486. host/router that processes the packet; if header fields are
  487. changed during processing (e.g., the Lifetime), the checksum is
  488. modified. If the checksum is not used, this field must be coded
  489. with a value of zero (0). See Appendix A for algorithms used in
  490. the computation and adjustment of the checksum.
  491.  
  492. 4.9  Destination Address Length Indicator ()
  493.  
  494. This field indicates the length, in octets, of the Destination
  495. Address.
  496.  
  497. 4.10  Destination Address
  498.  
  499. The format of the address encoded in this field is described in a
  500. companion addressing document, see [8].
  501.  
  502. For compatibility and interoperability with OSI use of CLNP, the
  503. initial octet of the Destination Address is assumed to be an
  504. Authority and Format Indicator, as defined in ISO 8348 [7]. A
  505. destination address may be between 8 and 20 octets long
  506. (inclusive).  The final octet of the destination address must
  507. always contain the value of the PROTO field, as defined in IP.
  508. The 8-bit PROTO field indicates the next level protocol used in
  509. the data portion of the CLNP datagram.  The values for various
  510. protocols are specified in "Assigned Numbers" [9]. For the PROTO
  511. field, the value of zero (0) is reserved.
  512.  
  513. 4.11  Source Address Length Indicator ()
  514.  
  515. This field indicates the length, in octets, of the Source
  516. Address.
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531. IETF                            Page 9
  532. January 6, 1993          CLNP for TUBA             Internet Draft
  533.  
  534.  
  535. 4.12  Source Address
  536.  
  537. The format of the address encoded in this field is described in a
  538. companion addressing document, see [8].
  539.  
  540. For compatibility and interoperability with OSI use of CLNP, the
  541. initial octet of the Destination Address is assumed to be an
  542. Authority and Format Indicator, as defined in ISO 8348 [7]. A
  543. destination address may be between 8 and 20 octets long
  544. (inclusive).  The final octet of the source address is reserved.
  545. It may be set to the protocol field value on transmission, and
  546. shall be ignored on reception (the value of zero must not be
  547. used).
  548.  
  549. 4.13  Data Unit Identifier
  550.  
  551. Like the Identification field of IP, this 16-bit field is used to
  552. distinguish segments of the same (original) packet for the
  553. purposes of reassembly.
  554.  
  555. 4.14  Fragment Offset
  556.  
  557. Like the Fragment Offset of IP, this 16-bit is used to identify
  558. the relative octet position of the data in this fragment with
  559. respect to the start of the data submitted to CLNP; i.e., it
  560. indicates where in the original datagram this fragment belongs.
  561.  
  562. 4.15  Options
  563.  
  564. All CLNP options are "triplets" of the form <parameter code>,
  565. <parameter lenth>, and <parameter value>.  Both the parameter
  566. code and length fields are always one octet long; the length
  567. parameter value, in octets, is indicated in the parameter length
  568. field. The following options are defined for CLNP for TUBA.
  569.  
  570. 4.15.1  _S_e_c_u_r_i_t_y
  571.  
  572. The value of the parameter code field is binary 1100 0101. The
  573. length field must be set to the length of a Basic (and Extended)
  574. Security IP option(s) as identified in RFC1108 [10], plus 1.
  575. Octet 1 of the security parameter value field -- the CLNP
  576. Security Format Code -- is set to a binary value 0100 0000,
  577. indicating that the remaining octets of the security field
  578. contain either the Basic or Basic and Extended Security options
  579. as identified in RFC 1108 [10]. This encoding points to the
  580. administration of the source address (e.g., ISOC) as the
  581. administration of the security option; it is thus distinguished
  582. from the globally unique format whose definition is reserved for
  583. OSI use.  Implementations must examine the PROTO field in the
  584. source address; if the value of PROTO indicates the CLNP client
  585. is TCP or UDP, the security option described in RFC1108 is used.
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597. IETF                            Page 10
  598. Internet Draft            CLNP for TUBA           January 6, 1993
  599.  
  600.  
  601. The formats of the Security option, encoded as a CLNP option, is
  602. as follows. The CLNP option will be used to convey the Basic and
  603. Extended Security options as sub-options; i.e., the exact
  604. encoding of the Basic/Extended Security IP Option is carried in a
  605. single CLNP Security Option, with the length of the CLNP Security
  606. option reflecting the sum of the lengths of the Basic and
  607. Extended Security IP Option.
  608.  
  609.  
  610. +--------+--------+--------+--------+--------+------//-----+---
  611. |11000100|XXXXXXXX|01000000|10000010|YYYYYYYY|             |          ...
  612. +--------+--------+--------+--------+--------+------//-----+------
  613.  CLNP       CLNP     CLNP     BASIC   BASIC    BASIC
  614.  OPTION    OPTION   FORMAT  SECURITY  OPTION   OPTION
  615.  TYPE      LENGTH    CODE    TYPE     LENGTH   VALUE
  616.  (197)                       (130)
  617.  
  618.  
  619.       ---+------------+------------+----//-------+
  620.  ...     |  10000101  |  000LLLLL  |             |
  621.     -----+------------+------------+----//-------+
  622.             EXTENDED     EXTENDED    EXTENDED OPTION
  623.             OPTION       OPTION          VALUE
  624.            TYPE (133)    LENGTH
  625.  
  626.  
  627.  
  628. The syntax, semantics and  processing of the Basic and Extended
  629. IP Security Options are defined in RFC1108.
  630.  
  631.  
  632. 4.15.2  _T_y_p_e__o_f__S_e_r_v_i_c_e
  633.  
  634. The value of the parameter code field must be set to a value of
  635. binary 1100 0011 (the CLNP Quality of Service Option Code point).
  636. The length field must be set to the length of the type of service
  637. field as identified in RFC1349, Type of Service in the Internet
  638. Protocol Suite [11], plus 1 (i.e., the value is 2). Octet 1 of
  639. the type of service parameter field is set to a binary value 0100
  640. 0000, indicating that the remaining octet of the Type Of Service
  641. field is to be encoded as described in RFC1349.  This encoding
  642. points to the administration of the source address (e.g., ISOC)
  643. as the administration of the CLNP QOS option; it is thus
  644. distinguished from the globally unique QOS format whose
  645. definition is reserved for OSI use.  Implementations must examine
  646. the PROTO field in the source address; if the value of PROTO
  647. indicates the CLNP client is TCP or UDP, the TOS described in
  648. RFC1349 is used.
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663. IETF                            Page 11
  664. January 6, 1993          CLNP for TUBA             Internet Draft
  665.  
  666.  
  667. +-----------+----------+----------+----------+
  668. | 1100 0011 | 00000010 | 01000000 | PPPTTTT0 |
  669. +-----------+----------+----------+----------+
  670.  CLNP QOS     OPTION    QOS FORMAT  IP TOS
  671.  TYPE (195)   LENGTH       CODE      OCTET
  672.  
  673.  
  674. The Type of Service octet consists of three fields:
  675.  
  676.  
  677.    0     1     2     3     4     5     6     7
  678. +-----+-----+-----+-----+-----+-----+-----+-----+
  679. |   PRECEDENCE    |          TOS          | MBZ |
  680. +-----+-----+-----+-----+-----+-----+-----+-----+
  681.  
  682. The first field, labeled "PRECEDENCE" above, is intended to
  683. denote the importance or priority of the datagram. The second
  684. field, labeled "TOS" above, denotes how the network should make
  685. tradeoffs between throughput, delay, reliability, and cost. The
  686. last field must be zero ("MBZ").
  687.  
  688. The processing of the type of service option is defined in
  689. RFC1349. The rules for applying TOS in Error and Report messages
  690. should correspond to those applied to the corresponding ICMP
  691. messages; i.e., error messages must always be sent with the
  692. default TOS; request messages may have any correct TOS value, and
  693. replies must be sent with the same value in the TOS field as was
  694. used in the corresponding request message.
  695.  
  696. [Editor's Note: It has been suggested that the IP precedence map
  697. directly into a CLNP option, Priority. The  feature will be
  698. provided irrespective of whether precedence is encoded in the TOS
  699. or Priority option.]
  700.  
  701. 4.15.3  _P_a_d_d_i_n_g
  702.  
  703. The padding field is used to lengthen the packet header to a
  704. convenient size. The parameter code field must be set to a value
  705. of binary 1100 1100. The value of the  parameter length field is
  706. variable. The parameter value may contain any value.
  707.  
  708.  
  709. +----------+----------+-----------+
  710. | 11001100 | LLLLLLLL | VVVV VVVV |
  711. +----------+----------+-----------+
  712.  
  713. 4.15.4  _S_o_u_r_c_e__R_o_u_t_i_n_g
  714.  
  715. Like the strict source route option of IP, the Complete Source
  716. Route option of CLNP is used to specify the exact and entire
  717. route an internet datagram must take. Similarly, the Partial
  718. Source Route option of CLNP provides the equivalent of the loose
  719. source route option of IP; i.e., a means for the source of an
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729. IETF                            Page 12
  730. Internet Draft            CLNP for TUBA           January 6, 1993
  731.  
  732.  
  733. internet datagram to supply (some) routing information to be used
  734. by gateways in forwarding the internet datagram towards its
  735. destination.
  736.  
  737. The parameter code for Source Routing is binary 1100 1000. The
  738. length of the source routing parameter value is variable.
  739.  
  740. The first octet of the parameter value is a type code, indicating
  741. Complete Source Routing (binary 0000 0001) or partial source
  742. routing (binary 0000 0000). The second octet identifies the
  743. offset of the next network entity title to be processed in the
  744. list, relative to the start of the parameter (i.e., a value of 3
  745. is used to identify the first address in the list). The third
  746. octet begins the list of network entity titles.
  747.  
  748. 4.15.5  _R_e_c_o_r_d__R_o_u_t_e
  749.  
  750. Like the IP record route option, the Record route option of CLNP
  751. is used to trace the route a CLNP datagram takes.
  752.  
  753. The parameter code for Record Route is binary 1100 1011. The
  754. length of the record route parameter value is variable.
  755.  
  756. The first octet of the parameter value is a type code, indicating
  757. Complete Source Route (0000 0001) Partial Recording of Route
  758. (0000 0000). The second octet identifies the offset where the
  759. next network entity title may be recorded (i.e., the end of the
  760. current list), relative to the start of the parameter (i.e., a
  761. value of 3 is used to identify the initial recording position).
  762. If recording of route has been terminated (I'll be back...), this
  763. octet has a value 255. The third octet begins the list of network
  764. entity titles.
  765.  
  766. 4.15.6  _T_i_m_e_s_t_a_m_p
  767.  
  768. [Editor's Note: There is no timestamp option in CLNP. We propose
  769. to define the option and submit it to ISO; temporarily, we will
  770. be most presumptuous and "borrow" a code point from the many that
  771. are reserved.]
  772.  
  773. This paper proposes that the parameter code value 1110 1110 be
  774. used to identify the Timestamp option, and that the syntax and
  775. semantics of Timestamp be identical to that defined in IP.
  776.  
  777. The Timestamp Option is defined in RFC 791. It is proposed that
  778. the parameter code 1110 1110 be used rather than the option type
  779. code 68 to identify the Timestamp option, and that the parameter
  780. value convey the option length. Octet 1 of the Timestamp
  781. parameter value shall be encoded as the pointer (octet 3 of IP
  782. Timestamp); octet 2 of the parameter value shall be encoded as
  783. the overflow/format octet (octet 4 of IP Timestamp); the
  784. remaining octets shall be used to encode the timestamp list. The
  785. size is fixed by the source, and cannot be changed to accommodate
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795. IETF                            Page 13
  796. January 6, 1993          CLNP for TUBA             Internet Draft
  797.  
  798.  
  799. additional timestamp information.
  800.  
  801.  
  802.         +--------+--------+--------+--------+
  803.         |11101110| length | pointer|oflw|flg|
  804.         +--------+--------+--------+--------+
  805.         |         network entity title      |
  806.         +--------+--------+--------+--------+
  807.         |             timestamp             |
  808.         +--------+--------+--------+--------+
  809.         |                 .                 |
  810.                           .
  811.  
  812.  
  813.  
  814. 5.  Error Reporting  and Control Message Handling
  815.  
  816. CLNP and IP  differ in the way in which errors are reported to
  817. hosts. In IP environments, the Internet Control Message Protocol
  818. (ICMP, [7]) is used to return (error) messages to hosts that
  819. originate packets that cannot be processed. ICMP messages are
  820. transmitted as user data in IP datagrams. Unreachable
  821. destinations, incorrectly composed IP datagram headers, IP
  822. datagram discards due to congestion, and lifetime/reassembly time
  823. exceeded are reported; the complete internet header that caused
  824. the error plus 8 octets of the segment contained in that IP
  825. datagram are returned to the sender as part of the ICMP error
  826. message. For certain errors, e.g., incorrectly composed IP
  827. datagram headers, the specific octet which caused the problem is
  828. identified.
  829.  
  830. In CLNP environments, an unique message type, the Error Report
  831. type, is used in the network layer protocol header to distinguish
  832. Error Reports from CLNP datagrams. CLNP Error Reports are
  833. generated on detection of the same types of errors as with ICMP.
  834. Like ICMP error messages, the complete CLNP header that caused
  835. the error is returned to the sender in the data portion of the
  836. Error Report. Implementations should return at least 8 octets of
  837. the datagram contained in the CLNP datagram to the sender of the
  838. original CLNP datagram. Here too, for certain errors, the
  839. specific octet which caused the problem is identified
  840.  
  841. A summary of the contents of the CLNP Error Report, as it is
  842. proposed for use in TUBA environments, is illustrated in Figure
  843. 5-1:
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861. IETF                            Page 14
  862. Internet Draft            CLNP for TUBA           January 6, 1993
  863.  
  864.  
  865.  
  866.     0                   1                   2                   3
  867.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  868.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  869.    |        ........Data Link Header........       | NLP ID        |
  870.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  871.    |Header Length  |     Version   | Lifetime (TTL)| 000 | Type=ER |
  872.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  873.    |  TOTAL Length of Error Report |           Checksum            |
  874.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  875.    | Dest Addr Len |               Destination Address...          |
  876.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  877.    |               ... Destination Address...                      |
  878.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  879.    |               ... Destination Address...                      |
  880.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  881.    |               ... Destination Address...                      |
  882.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  883.    |               ... Destination Address...                      |
  884.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  885.    | PROTO field   | Src  Addr Len |  Source  Address...           |
  886.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  887.    |               ... Source Address...                           |
  888.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  889.    |               ... Source Address...                           |
  890.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  891.    |               ... Source Address...                           |
  892.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  893.    |               ... Source Address...                           |
  894.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  895.    |       ... Source Address      | Reason for Discard (type/len) |
  896.    |                               |   1100 0001   | 0000 0010     |
  897.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  898.    |     Reason for Discard        |    Options...                 |
  899.    |   code        |   pointer     |                               |
  900.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  901.    |                           Options                             |
  902.    :                                                               :
  903.    |                                                               |
  904.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  905.  
  906.           Note that each tick mark represents one bit position.
  907.  
  908.  
  909.                         Figure 5-1. Error Report Format
  910.  
  911.  
  912. 5.1  Rules for processing an Error Report
  913.  
  914. The following is a summary of the rules for processing an Error
  915. Report:
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927. IETF                            Page 15
  928. January 6, 1993          CLNP for TUBA             Internet Draft
  929.  
  930.  
  931.    o+ An Error Report is not generated to report a problem
  932.      encountered while processing an Error Report.
  933.  
  934.    o+ Error Reports may not be fragmented (hence, the
  935.      fragmentation part is absent).
  936.  
  937.    o+ The Reason for Discard Code field is populated with one of
  938.      the values from Table 5-1.
  939.  
  940.    o+ The Pointer field is populated with number of the first
  941.      octet of the field that caused the Error Report to be
  942.      generated. If it is not possible to identify the offending
  943.      octet, this field must be zeroed.
  944.  
  945.    o+ If the Priority or Type of Service option is present in the
  946.      errored datagram, the Error Report shall specify the same
  947.      option, using the value specified in the original datagram.
  948.  
  949.    o+ If the Security option is present in the errored datagram,
  950.      the Error Report shall specify the same option, using the
  951.      value specified in the original datagram; if the Security
  952.      option is not supported, no Error Report is to be generated.
  953.  
  954.    o+ If the Complete Source Route option is specified in the
  955.      errored datagram, the Error Report must compose a reverse of
  956.      that route, and return the datagram along the same path.
  957.  
  958. 5.2  Comparison of ICMP and CLNP Error Messages
  959.  
  960. Table 5-1 provides a loose comparison of ICMP message types and
  961. codes to CLNP Error Type Codes (values in Internet ASCII):
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.  
  970.  
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993. IETF                            Page 16
  994. Internet Draft            CLNP for TUBA           January 6, 1993
  995.  
  996.  
  997. CLNP Error Type  Codes            | ICMP Message           (Type, Code)
  998. ----------------------------------|------------------------------------
  999. Reason not specified          (0) | Parameter Problem           (12, 0)
  1000. Protocol Procedure Error      (1) | Parameter Problem           (12, 0)
  1001. Incorrect Checksum            (2) | Parameter Problem           (12, 0)
  1002. PDU Discarded--Congestion     (3) | Source Quench               (4, 0)
  1003. Header Syntax Error           (4) | Parameter problem           (12, 0)
  1004. Need to Fragment could not    (5) | Frag needed, DF set         (3, 4)
  1005. Incomplete PDU received       (6) | Parameter Problem           (12, 0)
  1006. Duplicate Option              (7) | Parameter Problem           (12, 0)
  1007. Destination Unreachable     (128) | Network Unreachable         (3, 0)
  1008. Destination Unknown         (129) | Host Unreachable            (3, 1)
  1009. Source Routing Error        (144) | Source Route failed         (3, 5)
  1010. Source Route Syntax Error   (145) | Source Route failed         (3, 5)
  1011. Unknown Address in Src Route(146) | Source Route failed         (3, 5)
  1012. Path not acceptable         (147) | Source Route failed         (3, 5)
  1013. Lifetime expired            (160) | TTL exceeded                (11, 0)
  1014. Reassembly Lifetime Expired (161) | Reassembly time exceeded    (11, 1)
  1015. Unsupported Option          (176) | Parameter Problem           (12, 0)
  1016. Unsupported Protocol Version(177) | Parameter problem           (12, 0)
  1017. Unsupported Security Option (178) | Parameter problem           (12, 0)
  1018. Unsupported Src Rte Option  (179) | Parameter problem           (12, 0)
  1019. Unsupported Rcrd Rte        (180) | Parameter problem           (12, 0)
  1020. Reassembly interference     (192) | Reassembly time exceeded    (11,1)
  1021.  
  1022.  
  1023. Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages
  1024.  
  1025. Note 1: The current use of the source quench is only
  1026.         when packets are discarded, and thus the current use
  1027.         meaning is the same; if a future RFC describes a more
  1028.         robust treatment of the source quench, the applicability
  1029.         of this CLNP Error Report Type should be reconsidered.
  1030.  
  1031. Note 2: There are no corresponding CLNP Error Report Codes for the
  1032.         following ICMP error message types:
  1033.         - Protocol Unreachable  (3, 2)
  1034.         - Port Unreachable      (3, 3)
  1035.         [ED.    There are error code points available in the ER type
  1036.                 code block that can be used to identify these message types.]
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042. 6.  Pseudo-Header Considerations
  1043.  
  1044. A checksum is computed on UDP and TCP segments to verify the
  1045. integrity of the UDP/TCP segment. To further verify that the
  1046. UDP/TCP segment has arrived at its correct destination, a
  1047. pseudo-header consisting of information used in the delivery of
  1048. the UDP/TCP segment is composed and included in the checksum
  1049. computation.
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059. IETF                            Page 17
  1060. January 6, 1993          CLNP for TUBA             Internet Draft
  1061.  
  1062.  
  1063. To compute the checksum on a UDP or TCP segment prior to
  1064. transmission, implementations must compose a pseudo-header to the
  1065. UDP/TCP segment consisting of the following information that will
  1066. be used when composing the CLNP datagram:
  1067.  
  1068.    o+ Destination Address Length Indicator
  1069.  
  1070.    o+ Destination Address and PROTO
  1071.  
  1072.    o+ Source Address Length Indicator
  1073.  
  1074.    o+ Source Address and Reserved
  1075.  
  1076. The total length of the UDP/TCP segment is also included in the
  1077. checksum computation. Figure 5-1 illustrates the resulting
  1078. pseudo-header when both source and destination addresses are
  1079. maximum length.
  1080.  
  1081.  
  1082.     0                   1                   2                   3
  1083.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1084.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1085.    | Dest Addr Len |               Destination Address...          |
  1086.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1087.    |               ... Destination Address...                      |
  1088.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1089.    |               ... Destination Address...                      |
  1090.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1091.    |               ... Destination Address...                      |
  1092.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1093.    |               ... Destination Address...                      |
  1094.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1095.    | PROTO field   | Src  Addr Len |  Source  Address...           |
  1096.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1097.    |               ... Source Address...                           |
  1098.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1099.    |               ... Source Address...                           |
  1100.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1101.    |               ... Source Address...                           |
  1102.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1103.    |               ... Source Address...                           |
  1104.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1105.    |       ... Source Address      |   UDP/TCP segment length      |
  1106.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1107.  
  1108. Figure 5-1. Pseudo-header
  1109.  
  1110. If needed, an octet of zero is added to the end of the UDP/TCP
  1111. segment to pad the datagram to a length that is a multiple of 16
  1112. bits. In all other respects, rules for computing the checksum are
  1113. consistent with RFC 793 and RFC 768.
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125. IETF                            Page 18
  1126. Internet Draft            CLNP for TUBA           January 6, 1993
  1127.  
  1128.  
  1129. 7.  REFERENCES
  1130.  
  1131.  
  1132.  
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191. IETF                            Page 19
  1192. January 6, 1993          CLNP for TUBA             Internet Draft
  1193.  
  1194.  
  1195. [1]     ISO 8473--International Standards Organization--Data
  1196.         Communications-- Protocol for Providing the
  1197.         Connectionless-mode Network Service
  1198.  
  1199. [2]     Callon, R., TCP/UDP over Bigger Addresses (TUBA), Request for
  1200.         Comments 1347, Network Information Center, SRI
  1201.         International, Menlo Park, CA, May 1992.
  1202.  
  1203. [3]     Postel, J., Transmission Control Protocol (TCP). Request for
  1204.         Comments 793, Network Information Center, SRI
  1205.         International, Menlo Park, CA, 1981 September.
  1206.  
  1207. [4]     Postel, J., User Datagram Protocol (UDP). Request for Comments 768,
  1208.         Network Information Center, SRI International, Menlo Park, CA.
  1209.  
  1210. [5]     Postel, J., Internet Protocol (IP). Request for Comments 791,
  1211.         Network Information Center, SRI International, Menlo Park,
  1212.         CA, 1981 September.
  1213.  
  1214. [6]     Chapin, L., ISO CLNP, Draft International Standard version,
  1215.         Request for Comments 994, Network Information Center, SRI
  1216.         International, Menlo Park, CA.
  1217.  
  1218. [7]     ISO 8348--International Standards Organization--Data
  1219.         Communications--OSI Network Layer Addressing
  1220.  
  1221. [8]     Callon, R., Addressing for the new Internet.
  1222.         Request for Comments iiii, Network Information Center, SRI
  1223.         International, Menlo Park, CA.
  1224.  
  1225. [9]     Reynolds, J., and J. Postel, Assigned Numbers.
  1226.         Request for Comments 1340, Network Information Center, SRI
  1227.         International, Menlo Park, CA.
  1228.  
  1229. [10]    Kent, S., Security Option for IP,
  1230.         Request for Comments 1108, Network Information Center, SRI
  1231.         International, Menlo Park, CA.
  1232.  
  1233. [11]    Almquist, P., Type of Service in the Internet
  1234.         Protocol Suite. Request for Comments 1349, Network Information
  1235.         Center, SRI International, Menlo Park, CA.
  1236.  
  1237. [12]    ISO 6523 -- International Code Designators
  1238.  
  1239. [13]    Callon, R.,  NSAPA Guidelines for the Internet,
  1240.         Request for Comments RFC 1237, Network Information Center, SRI
  1241.         International, Menlo Park, CA.
  1242.  
  1243. [14]    Hagens, R. and C. Wittbrodt, CLNP Ping, Request for Comments
  1244.         1139, Network Information Center, SRI
  1245.         International, Menlo Park, CA.
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257. IETF                            Page 20
  1258. Internet Draft            CLNP for TUBA           January 6, 1993
  1259.  
  1260.  
  1261. Appendix A. Checksum Algorithms (from ISO 8473)
  1262.  
  1263.  
  1264.  
  1265. Symbols used in algorithms:
  1266.         c0, c1          variables used in the algorithms
  1267.         i               position of octet in header (first
  1268.                         octet is i=1)
  1269.         Bi              value of octet i in the header
  1270.         n               position of first octet of checksum (n=8)
  1271.         L               Length of header in octets
  1272.         X               Value of octet one of the checksum parameter
  1273.         Y               Value of octet two of the checksum parameter
  1274.  
  1275. Addition is performed in one of the two following modes:
  1276.  
  1277.    o+ modulo 255 arithmetic;
  1278.  
  1279.    o+ eight-bit one's complement arithmetic;
  1280.  
  1281. The algorithm for Generating the Checksum Parameter Value is as
  1282. follows:
  1283.  
  1284.   A.  Construct the complete header with the value of the
  1285.       checksum parameter field set to zero; i.e., c0 <- c1 <- 0;
  1286.  
  1287.   B.  Process each octet of the header sequentially from i=1 to L
  1288.       by:
  1289.  
  1290.          o+ c0 <- c0 + Bi
  1291.  
  1292.          o+ c1 <- c1 + c0
  1293.  
  1294.   C.  Calculate X, Y as follows:
  1295.  
  1296.          o+ X <- (L - 8)(c0 - c1) modulo 255
  1297.  
  1298.          o+ Y <- (L - 7)(-C0) + c1
  1299.  
  1300.   D.  If X = 0, then X <- 255
  1301.  
  1302.   E.  If Y = 0, then Y <- 255
  1303.  
  1304.   F.  place the values of X and Y in octets 8 and 9 of the
  1305.       header, respectively
  1306.  
  1307. The algorithm for checking the value of the checksum parameter is
  1308. as follows:
  1309.  
  1310.   A.  If octets 8 and 9 of the header both contain zero, then the
  1311.       checksum calculation has succeeded; else if either but not
  1312.       both of these octets contains the value zero then the
  1313.       checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323. IETF                            Page 21
  1324. January 6, 1993          CLNP for TUBA             Internet Draft
  1325.  
  1326.  
  1327.   B.  Process each octet of the header sequentially from i = 1 to
  1328.       L by:
  1329.  
  1330.          o+ c0 <- c0 + Bi
  1331.  
  1332.          o+ c1 <- c1 + c0
  1333.  
  1334.   C.  When all the octets have been processed, if c0 = c1 = 0,
  1335.       then the checksum calculation has succeeded, else it has
  1336.       failed.
  1337.  
  1338. There is a separate algorithm to adjust the checksum parameter
  1339. value when a octet has been modified (such as the TTL). Suppose
  1340. the value in octet k is changed by Z = newvalue - oldvalue. If X
  1341. and Y denote the checksum values held in octets n and n+1
  1342. respectively, then adjust X and Y as follows:
  1343.  
  1344. If X = 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then
  1345. the checksum is incorrect, else:
  1346.  
  1347. X <- (k - n - 1)Z + X   modulo 255
  1348.  
  1349. Y <- (n - k)Z + Y       modulo 255
  1350.  
  1351. If X = 0, then X <- 255; if Y = 0, then Y <- 255.
  1352.  
  1353. In the example, n = 89; if the octet altered is the TTL (octet
  1354. 4), then k = 4. For the case where the lifetime is decreased by
  1355. one unit (Z = -1), the assignment statements for the new values
  1356. of X and Y in the immediately preceeding algorithm simplify to:
  1357.  
  1358. X <- X + 5      Modulo 255
  1359.  
  1360. Y <- Y - 4      Modulo 255
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367.  
  1368.